<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>



<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="umsroot.css">
<TITLE>
Concepts
</TITLE>
</HEAD>
<BODY >
<A HREF="umsroot105.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="umsroot104.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="umsroot107.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2 CLASS="section"><A NAME="htoc232">17.2</A>&nbsp;&nbsp;Concepts</H2><UL>
<LI><A HREF="umsroot106.html#toc128">The Structured Resolvent</A>
<LI><A HREF="umsroot106.html#toc129">Floundering</A>
</UL>

<A NAME="toc128"></A>
<H3 CLASS="subsection"><A NAME="htoc233">17.2.1</A>&nbsp;&nbsp;The Structured Resolvent</H3>
<A NAME="@default949"></A>
The term <B>resolvent</B> originates from Logic Programming.
It is the set of all goals that need to be satisfied.
The computation typically starts with a resolvent consisting only of the top-level goal
(the initial query).
This then gets successively transformed (by substituting goals that
match a clause head with an instance of the clause body, ie. a
sequence of sub-goals),
and eventually terminates with one of the trivial goals
<B>true</B> or <B>fail</B>.
For example, given the program
<BLOCKQUOTE CLASS="quote"><PRE CLASS="verbatim">
p :- q, r.    % clause 1
q :- true.    % clause 2
r :- q.       % clause 3
</PRE></BLOCKQUOTE>
and the goal p, the resolvent goes through the following states
before the goal is proven (by reduction to true) and the computation terminates:
<BLOCKQUOTE CLASS="quote"><PRE CLASS="verbatim">
p --1--&gt; (q,r) --2--&gt; (true,r) ----&gt; (r) --3--&gt; (q) --2--&gt; true
</PRE></BLOCKQUOTE>
<A NAME="@default950"></A>
While in Prolog the resolvent is always processed from left to right
like in this example,
the resolvent in ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> is more structured, and can be manipulated
in a much more flexible way.
This is achieved by two basic mechanisms, <B>suspension</B>
and <B>priorities</B>.<BR>
<BR>
<A NAME="@default951"></A>
<B>Suspended</B> goals form the part of the resolvent which is
currently not being considered. This is typically done when we
know that we cannot currently infer any interesting information from them.<BR>
<BR>
<A NAME="@default952"></A>
The remaining goals are ordered according to their <B>priority</B>.
At any time, the system attempts to solve the most urgent subgoal first.
ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> currently supports a fixed range of 12 different priorities,
priority 1 being the most urgent and 12 the least urgent.<BR>
<BR>
Figure <A HREF="#figresolv">17.1</A> shows the structure of the resolvent.
When a toplevel goal is launched, it has priority 12 and is the only
member of the resolvent. As execution proceeds, active goals may be
suspended, and suspended goals may be woken and scheduled with a
particular priority.
<BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<IMG SRC="umsroot011.gif">
<BR>
<BR>
<DIV CLASS="center">Figure 17.1: Structure of the resolvent</DIV><BR>
<BR>

<A NAME="figresolv"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></BLOCKQUOTE>
<A NAME="toc129"></A>
<H3 CLASS="subsection"><A NAME="htoc234">17.2.2</A>&nbsp;&nbsp;Floundering</H3>
<A NAME="@default953"></A>
The case that a subgoal remains suspended (delayed) at the end of the computation
<A NAME="@default954"></A> is sometimes referred to as <I>floundering</I>.
When floundering occurs, it means that the resolvent could not be reduced
to true or fail, and that the answer bindings that have been found
are valid only under the assumption that the remaining delayed goals
are in fact true. Since such a conditional answer is normally not
satisfactory (even though it may be correct), it is then necessary to change
the control aspect of the program. The solution would usually be to either
make further variable instantiations or to change control annotations.
The aim is to get the delayed goals out of the suspended state and
into the scheduled state, where they will eventually be executed and reduced.
As a rule of thumb, goals will not suspend when all their arguments are
fully instantiated. Therefore, a program that makes sure that all its
variables are instantiated at the end of computation will typically not
suffer from floundering.<BR>
<BR>
<HR>
<A HREF="umsroot105.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="umsroot104.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="umsroot107.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
